More Effective Agile
https://images-na.ssl-images-amazon.com/images/I/510CEpQb5tL._SX350_BO1,204,203,200_.jpg
読了 : 2020-10-02
本書に寄せて
“アジャイルを始めたばかりの人は 「第23章 より効果的なアジャイル:導入」 から読んでみよう。 私は、アジャイルを成功させるための土台をきちんと整えずに 「完全なアジャイル」 に突き進む組織をいやというほど見てきた
Part 1 : より効果的なアジャイル
1 章 : はじめに
本書の対象読者 : アジャイルの導入を効果的なものにしたいと考えている C レベルの責任者 (CxO)、VPoE、ディレクター、マネジャー、その他のソフトウェアチームや組織のリーダー 最も重要なこと : あなたの組織がアジャイル開発を採用していて、その結果に満足していない場合
本書の構成 : 背景状況 → 個人とチーム → (個人とチームが用いる) 作業プラクティス → (チームが作業プラクティスを用いる) 組織 → まとめと今後の展望
2 章 : アジャイルの本当の違いは何か
プランニングや要求獲得を事前に 100 % 終わらせる、というようなウォーターフォール開発との比較は 20 年前には意味があったかもしれないが、そのような厳密なウォーターフォール開発は実際には広く用いられていない
広く用いられているのは工程による開発
アジャイルアプローチとシーケンシャルアプローチの共通点
いずれでも、順調に進むプロジェクトは、管理をきちんと行うことと、顧客とのハイレベルなコラボレーションを重視
高品質な要求、設計、コーディング、テストに重点的に取り組む
アジャイルの恩恵の源
リリースサイクルが短い / 小さいバッチで実行するエンドツーエンドの開発作業
欠陥を見つけてもコストをかけずに修正しやすく、身動きが取れなくなる時間が短い
顧客からのフィードバックがすぐに得られて、迅速な軌道修正が可能になり、収益の増加と経費削減がしやすい
ジャストインタイムの計画
詳細な計画に費やす時間を減らせる (詳細な計画は捨てられやすいため)
ジャストインタイムの要求
事前の要求獲得に費やす時間を減らせる (あとから要求が変更されれば無意味になる)
創発的な設計
あとから変更される要求に対する事前の設計に費やす作業量が少なくなる効果
不確かな要求に対する事前の設計は間違いのもとであり、経済的でない
開発チームに統合された自動テスト
欠陥発見までのフィードバックループを短くし、欠陥修正コストを下げる。 初期コード品質を重視することに繋がる
頻繁な構造化コラボレーション
要求、設計、その他の活動の不備を引き起こす原因となりえるコミュニケーションの行き違いを減らす
実証主義的な改善モデルに焦点を合わせる
チームが経験からすばやく学びながら徐々に改善していく
アジャイルは不可分な概念ではなく、アジャイルプラクティスのそれぞれを個別に採用できる
組織によって重視するところは違うため、必要なものを採用すべし
ほとんどの組織はエンドツーエンドのアジリティ実現には至らない
アジャイルの境界を意識することが大事 : 現在の境界はどこにあり、望ましい境界はどこか?
3 章 : 複雑さと不確実さという問題に対処する
OODA : 複雑さや不確実さを前にして意思決定を行うためのモデル 4 章 : より効果的なアジャイルの始まり : スクラム
ソフトウェア業界でかかわるうえでの難題は 「コード & フィックス開発」 を防ぐこと
事前の見通しや計画を立てずにコードを書き、そのコードが動くまでデバッグする手法
アジャイル開発は短期集中型でコード中心なので、アジャイル開発のプラクティスを実践しているのかコード & フィックス開発をしているのか見分けがつきにくい
シーケンシャルアプローチは官僚主義でつまづくが、アジャイル開発は無秩序でつまづく
アジャイルの最初の取り組みや、アジャイルな取り組みがうまくいっていない場合は、スクラムから始めるのが良い